home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Suzy B Software 2
/
Suzy B Software CD-ROM 2 (1994).iso
/
extras
/
programm
/
gemfsc19
/
gemfsc19.lzh
/
GEMFUNCS
/
LCBUG.C
< prev
next >
Wrap
C/C++ Source or Header
|
1993-05-08
|
2KB
|
45 lines
In setting up my gemfast libraries to work in all memory models, I've run
across what looks like a bug in handling __saveds in prototypes. If a
base-relative memory model is in use, any declaration of a function pointer
argument in a prototype that includes __saveds will give an argument type
mismatch error when you try to pass a function name as a function pointer.
Different compilers and memory models need different options for defining
a G_USERDEF drawing function. For portability between compilers, I define
a GCALLBACK macro with the keywords the host compiler needs. For LC, that
means "far __stdargs __saveds". This macro is used both to define the
function, and to declare arguments in prototypes where I sometimes pass
pointers to G_USERDEF functions around. Stripping out a lot of gemfast
internals smoke-and-mirrors, here's a little demo of the problem...
#define GCALLBACK far __stdargs __saveds
typedef void GCALLBACK (GCALLBACKFUNC)(void);
extern void yfunc(GCALLBACKFUNC *);
static void GCALLBACK xfunc(void)
{
return;
}
void main(void)
{
yfunc(xfunc); // <-- xfunc flagged as "argument type incorrect"
}
The LC manual says __saveds is ignored in external declarations, but
apparently it is neither ignored nor handled properly in argument
declarations within prototypes. Interestingly, if you leave the __saveds
out of the argument in the prototype, but use it in defining the function,
you *don't* get a type mismatch. (Which is fine I guess, since it affects
only the codegen at definition time, but not how the function is called.)
I've discovered a klugey workaround, wherein I just #define __saveds to
nothingness before my big block of prototypes in gemfast.h, then #undef
it at the end of the header (so that it will be in effect during function
definitions in modules that #include <gemfast.h>), but such a workaround
shouldn't really be necessary.